Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion

crates/cairo-lang-parser/src/db.rs line 53 at r1 (raw file):

/// Parses a file and returns the result and the generated [ParserDiagnostic].
#[salsa::tracked(returns(ref))]
pub fn file_syntax_data<'db>(db: &'db dyn Database, file_id: FileId<'db>) -> SyntaxData<'db> {

you don't need it - you have all the members of ParserGroup as the selectors for this data struct.

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @orizi)

crates/cairo-lang-parser/src/db.rs line 53 at r1 (raw file):

Ok, so cant we just make the syntax_file function part of the query group? As it's used in existing selectors anyway. And we don't want to duplicate logic of choosing right selector based on the FileId kind

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @wawel37)

crates/cairo-lang-parser/src/db.rs line 53 at r1 (raw file):

i still don't see WHY you need it - what is the actual context?

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @orizi)

crates/cairo-lang-parser/src/db.rs line 53 at r1 (raw file):

Why do we need to bother asserting in file_module_syntax, file_expr_syntax and file_statement_list_syntax for certain kinds, if we just want to get the SyntaxNode, no matter of the kind.
Here's this logic in lint: https://github.com/software-mansion/cairo-lint/blob/94a0ac6bf5bfeb7ce9308831f52aade3293fb9bd/src/upstream.rs#L8.
Here's same logic in LS: https://github.com/software-mansion/cairols/blob/8eb59905cf23be2fe2bf2d1a8a930411e9fa3933/src/lang/db/upstream.rs#L8.

Those 3 methods use the file_syntax beneath anyway, so why would we don't want to simplify it?

@orizi reviewed 1 of 2 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @wawel37)

@piotmag769 reviewed 1 of 1 files at r2, 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @wawel37)